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EXECUTIVE  SUMMARY 

The  Joint  Tactical  Radio  System  (JTRS)  Acquisition  Program  was  born  out  of  the 
the  1997  Quadrennial  Defense  Review  (QDR),  which  called  for  the  services  to  combine 
and  integrate  all  tactical  radio  equipment.  The  essential  premise  behind  this  project  is  to 
leverage  commercial  off-the-shelf  (COTS)  and  software  defined  radio  (SDR)  technology 
to  produce  a  new  family  of  tactical  radios  that  are  multi-functional  and  complete  with 
advanced  data  networking  capabilities  to  meet  the  needs  of  modern  information  warfare. 
The  main  objective  of  JTRS  is  to  interconnect  radios  in  a  mobile  ad  hoc  network 
(MANET).  However,  conventional  routing  protocols  are  unable  to  meet  the  unique 
requirements  of  MANET.  Dynamic  topology,  bandwidth,  power  limitations,  and  limited 
physical  security  combine  to  make  the  MANET  very  challenging.  The  first  generation  of 
JTRS,  the  Digital  Modular  Radio,  is  being  installed  in  the  new  Marine  amphibious  ships 
currently  under  construction. 

The  Zone  Routing  Protocol  (ZRP),  developed  at  Cornell  University,  has  been 
suggested  for  implementation  in  JTRS.  ZRP  incorporates  a  hybrid  protocol  which 
utilizes  current  Internet  routing  techniques  combined  with  on-demand  routing  to  reduce 
overhead  and  improve  efficiency  in  MANET.  ZRP  forms  a  conventional  Internet  routing 
zone  around  each  mobile  node  and  only  executes  an  on-demand  routing  protocol  to  meet 
out-of-zone  destination  requests.  The  routing  zones  of  each  mobile  node  provide  the  out- 
of-zone  routing  protocol  a  more  efficient  method  of  creating  and  establishing  routes 
among  mobile  nodes. 

Utilizing  an  OPNET  model  of  ZRP  provided  by  Cornell  University,  this  thesis 
studied  and  examined  the  protocol's  performance  by  developing  a  simple  Marine  tactical 
scenario.  The  focus  of  the  analysis  was  on  protocol  overhead,  network  adaptation, 
efficiency,  and  optimization.  Techniques  and  recommendations  for  future  study  of  ZRP 
and  other  MANET  protocols  being  considered  for  use  in  JTRS  and  DMR.  The  results 
provide  a  snapshot  into  the  performance  of  ZRP  in  a  simple  network  chosen  to  represent 
the  relative  scale  of  a  single  Marine  rifle  platoon  operating  in  a  one  square  kilometer  area 
of  operation. 

The  overhead  traffic  generated  by  ZRP  was  consistent  with  that  of  a  hybrid 
MANET  protocol.  By  adjusting  the  size  of  the  conventional  Internet  routing  zone  around 
each  node,  ZRP  could  be  optimized  for  the  Marine  scenario.  The  amount  of  overhead 
generated  by  each  mobile  node's  routing  zone  was  dictated  by  the  size  of  its  routing  zone 
and  was  not  impacted  by  mobile  node  velocity.  The  amount  of  overhead  generated  by  the 
on-demand  protocol  for  out-of-zone  requests  was  dictated  by  the  volume  of  traffic  from 
each  mobile  node  and  the  velocity  of  the  mobile  nodes  in  the  network.  Link  performance 
was  increased  as  the  size  of  the  routing  zone  was  increased.  However,  the  efficiency  of 
the  routing  algorithm  was  decreased  on  a  similar  scale.  The  velocity  of  the  mobile  nodes 
had  a  detrimental  effect  on  link  stability.  Previous  techniques  of  optimization  developed 
at  Cornell  University  were  also  demonstrated  along  with  the  Marine  scenario  results. 

xiii 


The  ZRP  model  utilized  in  this  work  did  not  incorporate  several  important 
MANET  environmental  factors  to  adequately  model  the  JTRS  battlespace.  The  power 
levels,  source  traffic,  and  antenna  characteristics  of  each  node  need  to  be  made  ad  hoc  in 
nature.  Furthermore,  node  movement  should  be  reconfigured  to  provide  formation 
movements  to  simulate  tactical  formations  with  appropriate  movement  and  radio 
capabilities.  Vehicle,  foot,  helicopter,  and  aircraft  traffic  could  be  represented  by  varying 
the  velocity  of  some  nodes.  Foot  mobile  traffic  could  carry  squad  radios  with  limited 
transmit  ranges  and  vehicles,  helicopters,  and  aircraft  could  have  greater  transmitter 
coverage.  One  hundred  or  more  MANET  nodes  are  needed  to  accurately  model  the 
protocol  behavior  of  ZRP.  However,  the  Windows  NT  platform  utilized  for  this  work 
limited  the  numbers  of  nodes  that  could  be  placed  in  a  scenario  due  to  processing  power 
limitations. 
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I.  INTRODUCTION 

The  Joint  Tactical  Radio  System  (JTRS)  Acquisition  program  was  born  out  of  the 
1997  Quadrennial  Defense  Review  (QDR),  which  called  for  the  services  to  combine  and 
integrate  all  tactical  radio  development  [1].  The  essential  premise  behind  this  project  is 
to  leverage  commercial-off-the-shelf  (COTS)  and  software  defined  radio  (SDR) 
technology  to  produce  a  new  family  of  tactical  radios  that  are  multi-functional  and 
complete  with  advanced  wireless  data  networking  capabilities  to  meet  the  needs  of 
modern  information  warfare.  The  most  aggressive  objective  of  JTRS  is  the  ability  to 
form  the  radios  into  a  mobile  ad  hoc  network  (MANET)  [1].  The  first  generation  of 
JTRS,  the  Digital  Modular  Radio  (DMR),  has  been  incorporated  into  Marine  amphibious 
shipping  currently  under  construction  (LPD-17). 

Conventional  routing  protocols  are  unable  to  meet  the  unique  requirements  of 
MANET.  Dynamic  topology,  bandwidth  and  power  limitations,  and  limited  physical 
security  combine  to  make  the  MANET  environment  challenging  [2].  All  facets  of 
MANET  exhibit  ad  hoc  behavior;  bit  rates,  quality  of  service  (QoS),  infrastructure, 
mobility  patterns,  and  mobility  characteristics  [3].  This  wide  range  of  operating 
configurations  poses  an  enormous  challenge  to  routing  efficiency.  Traditional  shortest- 
path  routing  algorithms,  such  as  the  Distributed  Bellman-Ford  (DBF)  algorithm,  incur 
large  update  message  penalties  and  exhibit  slow  convergence  [3].  The  requirement  to 
reduce  overhead  and  improve  convergence  has  driven  researchers  to  examine  protocols 
with  proactive  path  finding  algorithms,  which  combine  distance  vector  and  link  state 
approaches  [3].  On-demand  discovery  of  routes  can  result  in  further  overhead  reductions 
compared  to  table-driven  methods  (e.g.  link-state  and  distance  vector),  but  suffer  from 
latency  due  to  route  discovery  delays.  A  hybrid  combination  of  on-demand  and  proactive 
techniques  has  produced  a  more  efficient  routing  protocol  [2]. 

The  Zone  Routing  Protocol  (ZRP),  developed  by  Haas  and  Pearlman  [4], 
incorporates  a  hybrid  protocol  that  exploits  the  benefits  of  both  reactive  and  proactive 
protocols  and  has  been  suggested  for  possible  implementation  in  the  Joint  Tactical  Radio 
System  (JTRS)  for  the  United  States  military  [1].  In  ZRP,  each  node  has  a  proactive  zone 
around  it,  which  is  dictated  by  an  adjustable  zone  routing  radius.  The  zone  routing  radius 
is  directly  related  to  hop  counts  from  the  node.  Routes  outside  the  zone  are  determined 
by  a  reactive  query  that  leverages  the  zone  structure  of  the  MANET  using  ZRP.  The 
intent  behind  this  MANET  routing  approach  is  to  leverage  routing  knowledge  in  a 
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localized  region  and  reach  out  to  selected  network  nodes  as  opposed  to  flooding  a 
network  to  locate  a  destination. 

The  objective  of  this  thesis  is  to  study  and  analyze  the  Zone  Routing  Protocol 
(ZRP)  for  MANET  environments  using  an  OPNET  simulation  provided  by  Haas  and 
Pearlman  [4].  The  focus  of  the  analysis  will  be  on  protocol  overhead,  network 
adaptation,  efficiency,  and  routing  zone  optimization.  Furthermore,  the  objective  is  to 
produce  techniques  and  recommendations  for  future  application  of  ZRP  and  other 
MANET  protocols  being  considered  for  use  in  the  JTRS  and  DMR.  The  results  presented 
provide  a  snapshot  into  the  performance  of  ZRP  in  a  small  generic  network  chosen  to 
represent  the  relative  scale  of  a  single  Marine  rifle  platoon  operating  in  a  one  square 
kilometer  area  of  operation. 

Chapter  II  begins  with  an  introduction  into  the  MANET  environment  and  routing 
protocols.  Hierarchical  State  Routing  (HSR)  and  Temporally  Ordered  Routing  Algorithm 
(TORA)  are  used  to  illustrate  MANET  protocols.  The  third  chapter  introduces  ZRP  and 
explains  its  method  of  operation.  Chapter  IV  provides  the  reader  with  an  understanding 
of  the  ZRP  model  and  OPNET  package  used  in  this  work.  Chapter  V  presents  the  results 
of  the  simulation  and  analysis.  Conclusions  and  recommendations  are  included  in  the 
final  chapter. 


II.  MOBILE  AD  HOC  NETWORK  PROTOCOLS 

A  MANET  is  a  network  environment  where  both  the  user  nodes  and  the 
infrastructure  itself  are  constantly  in  transition.  There  is  no  reliance  on  pre-existing  fixed 
infrastructure,  such  as  wireline  backbone  or  network  connectivity  via  satellite  links. 
MANETs  are  intended  to  function  independent  of  the  fixed  infrastructure  with  the 
exception  of  a  few  "stub"  gateways  to  provide  access  to  the  larger  network.  Figure  1 
provides  an  illustration  of  the  differences  between  MANET,  traditional  fixed 
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Figure  1.  MANET  Layer  In  Perspective  (After  Ref.  [2]). 


Internet,  and  Mobile  IP.  The  traditional  fixed  Internet  is  stable  with  little  or  no 
host/router  mobility.  Mobile  IP  attempts  to  give  the  hosts  more  mobility,  but  still 
requires  a  connection  to  the  fixed  network.  As  depicted  in  Figure  1,  a  MANET  node  is 
truly  mobile  and  is  itself  a  router  with  multiple  wireless  or  wired  connections.  A 
MANET  has  four  distinct  characteristics,  which  together  form  unique  underlying 
assumptions,  design  considerations,  and  concerns  that  are  not  revealed  in  static 
networking:  dynamic  topology,  bandwidth  constraints,  energy  constraints,  and  limited 
physical  security  [2].  Communication  protocols  for  this  demanding  environment  must  be 
adaptable,  self-organizing,  robust,  and  efficient  enough  to  meet  the  constrained  resources. 
Conventional  routing  protocols  associated  with  a  static,  fixed  infrastructure  internet  are 
unable  to  meet  the  unique  requirements  in  a  MANET  environment  due  to  considerable 
overhead  and  slow  reaction  to  topological  changes. 


In  a  MANET,  each  node  has  a  unique  internet  protocol  (IP)  address.  Routers  use 
a  routing  protocol  to  learn  about  the  network  and  to  determine  the  optimal  path  for 
sending  a  packet  to  a  destination.  The  routing  protocol  functions  at  the  network  layer  (see 
Figure  2)  to  perform  this  function.  MANET  protocols  utilize  the  following  basic  services 
from  the  lower  three  levels:  link  status,  packet  delivery,  and  network  layer  address  [2]. 
The  following  sections  will  examine  conventional  and  MANET  routing  protocols  in  more 
detail  before  looking  at  ZRP  in  Chapter  HI. 


Application 
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Data  Link 
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MANET  ROUTING 
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Figure  2.  Typical  Protocol  Stack  for  MANETs. 


A.         CONVENTIONAL  ROUTING  PROTOCOLS 


Conventional  routing  protocols  use  either  distance  vector  or  link-state  algorithms 
to  determine  the  most  efficient  path  to  a  destination.  Distance  vector  algorithms  require 
each  router  to  maintain  a  table  with  routes  to  all  possible  destinations  along  with  an 
associated  metric  that  is  collected  on  a  periodic  basis.  The  routing  overhead  remains 
constant  regardless  of  the  amount  of  host  movement.  This  type  of  method  is  closely 
associated  with  the  distributed  Bellman-Ford  routing  alogrithm.  A  version  of  Bellman- 
Ford  is  still  being  used  today  with  the  Router  Internet  Protocol  (RIP).  In  RIP,  for  each 
entry  the  next  hop  to  the  destination  is  stored  along  with  a  metric  to  reach  the  destination. 
The  metric  can  be  based  on  distance,  total  delay,  or  the  cost  of  sending  the  message  [5]. 
Each  node  shares  its  internal  information  periodically  through  update  broadcasts  to 
neighboring  nodes.  The  routers  utilize  the  updates  to  constantly  revise  their  routing 
tables  for  shortest-path  calculations.  Link-state  algorithms  operate  in  a  similar  manner 
but  are  event  driven  by  changes  in  the  link  status  of  nodes.  Path-finding  algorithms 
provide  a  hybrid  approach  utilizing  both  distance  vector  and  link-state  algorithms  [13]. 

Although  distance  vector  and  link-state  algorithms  are  very  effective  for  achieving 

routing  optimization,  the  overhead  associated  with  these  techniques  is  considerable  and 

exhibits  slow  convergence  due  to  topological  changes.  A  simulation  study  was  conducted 
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by  Lee,  Gerla,  and  Toh  [5],  which  analyzed  RIP  in  a  MANET  and  highlighted  shortfalls 
of  conventional  routing  protocols.  In  RIP,  a  conventional  protocol,  routing  updates  are 
produced  on  a  periodic  basis.  According  to  the  study,  RIP  does  not  scale  well  to  large 
networks,  because  each  network  node  requires  N  iterations  to  detect  a  node  that  is 
disconnected,  where  N  represents  the  number  of  nodes.  This  is  known  as  the  count  to 
infinity  problem.  On-demand  protocols  have  clear  proportional  increase  in  overhead  due 
to  node  mobility.  Figure  3  depicts  the  overhead  associated  with  periodic,  on-demand,  and 
hybrid  protocols  as  a  function  of  mobility.  As  clearly  shown  in  Figure  3,  the  study 
determined  that  a  hybrid  proctocol  is  needed  to  meet  the  requirements  of  MANET. 
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Figure  3.  Behavior  of  On-demand  and  Periodic  Mechanisms  (From  Ref.  [6]). 


B. 


TABLE  DRIVEN  VS  ON-DEMAND  PROTOCOLS 


Two  distinct  types  have  emerged  from  the  development  of  MANET  protocols: 
table-driven  and  on-demand  [7].  In  table-driven  algorithms,  current  routing  information 
is  maintained  at  each  node.  Table-driven  algorithms  are  adaptations  of  the  distance 
vector  and  link-state  techniques.  The  constant  routing  updates,  different  types  of  tables, 
distributions,  and  techniques  are  used  to  increase  efficiency.  In  contrast,  on-demand 
protocols  attempt  to  reduce  overhead  and  are  more  responsive  to  MANET  by  having  the 
source  node  dictate  requirements.    Routes  are  created  on  an  as-required  basis  by  the 


source  node.  As  depicted  in  Figure  3,  a  hybrid  protocol  combining  both  periodic  and  on- 
demand  qualities  responds  to  the  needs  of  the  network  without  creating  excessive  traffic 
overhead.  All  routes  created,  both  on-demand  and  periodic,  hold  a  time  stamp  to 
eliminate  outdated  routes. 

There  are  several  types  of  MANET  protocols  being  considered  by  the  Internet 
Engineering  Task  Force  (IETF)  MANET  Working  Group  that  are  table-driven  (periodic) 
or  on-demand.  Some  examples  of  table-driven  MANET  protocols  are  the  Dynamic 
Destination-Sequenced  (DSDV),  Wireless  Routing  Protocol  (WRP),  Global  State 
Routing  (GSR),  Fisheye  State  Routing  (FSR),  Hierarchical  State  Routing  (HSR),  Zone- 
based  Hierarchical  Link  State  Protocol  (ZHLS),  and  Cluster  Head  Gateway  Switch 
Routing  Protocol  (CGSR).  DSDV  is  based  on  the  classic  Bellman-Ford  algorithm.  WRP 
is  a  table-based  distance  vector  routing  protocol.  GSR  is  similar  to  DSDV,  but  takes  the 
idea  of  link-state  routing  and  improves  it  by  limiting  the  flooding  of  table  updates.  FSR 
improves  on  GSR  by  limiting  the  size  of  update  broadcasts.  ZHLS  is  similar  to  HSR  and 
divides  the  network  into  non-overlapping  zones,  but  unlike  HSR,  there  is  no  cluster  head. 
CGSR  is  a  combination  of  ZHLS  and  DSDV.  Examples  of  on-demand  MANET 
protocols  include  the  Cluster  Based  Routing  Protocol  (CBRP),  Ad  Hoc  On-Demand 
Distance  Vector  Routing  (AODV),  Dynamic  Source  Routing  Protocol  (DSR),  Temporally 
Ordered  Routing  Algorithm  (TORA),  Associativity  Based  Routing  (ABR),  and  Signal 
Stability  Routing  (SSR).  GBRP  combines  the  cluster  technique  with  on-demand  routing. 
AODV  is  a  combination  of  DSDV  and  on-demand  routing.  DSR  is  an  on-demand 
protocol  initiated  by  the  source  node  and  focuses  on  route  discovery  and  route 
maintenance.  ABR  defines  a  new  routing  approach  with  a  metric  based  on  link  stability. 
SSR  also  defines  a  new  metric  approach  based  on  node  signal  strength  and  location 
stability.  HSR  and  TORA  will  be  explained  in  the  following  sections  to  introduce  a 
protocol  from  each  category. 

1.  Hierarchical  State  Routing  (HSR) 

HSR  combines  the  ideas  of  zone  routing  with  a  hierarchical  structure  and  is 
clearly  linked  with  conventional  table-driven  protocols.  As  depicted  in  Figure  4,  nodes 
are  broken  up  into  routing  zones  at  the  physical  network  layer  and  selected  nodes  (cluster 
heads)  become  members  of  a  virtual  hierarchical  tree  similar  to  that  in  the  Internet. 
Routing  information  is  controlled  in  a  tree  data  structure  fashion.  Each  routing  zone  on 
the  physical  layer  is  tied  together  by  a  cluster  head,  which  serves  as  the  virtual  leader  of 


the  routing  zone.  The  cluster  head  is  periodically  elected  and  collects  all  the  routing  data 
from  the  zone  and  distributes  all  the  zone's  routes  to  other  cluster  heads  on  a  virtual  layer. 
The  cluster  heads  provide  the  medium  to  share  routing  information  in  a  hierarchical  tree 
architecture.  Selected  cluster  heads  are  promoted  to  higher  levels  in  the  tree  data 
structure  up  to  the  root  node  and  pass  routing  information  among  themselves  on  virtual 
layers.  The  cluster  heads  serve  as  the  conduit  to  the  upper  and  lower  level  cluster  heads 
to  ensure  that  all  routing  information  is  distributed  to  all  levels.  A  gateway  node  is  a 
node  that  resides  in  more  than  one  zone  and  can  communicate  with  nodes  in  both  zones. 
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Figure  4.  An  Example  of  Clustering  in  HSR  (After  Ref.  [7]). 


As  shown  in  Figure  4,  the  nodes  are  partitioned  into  subnetworks  (Level  0,  Level 
1,  and  Level  2)  according  to  the  respective  level  in  the  hierarchical  tree  structure.  A 
Location  Management  Server  (LMS)  handles  address  assignments  for  each  subnetwork. 
Nodes  that  desire  to  operate  in  the  subnetwork  must  register  with  the  LMS  to  obtain  an 
address.  Each  node  is  assigned  a  logical  address  <subnet,host>  by  their  respective  LMS. 


The  LMS  functionality  is  similar  to  that  of  a  Domain  Name  Server  (DNS)  in  the  Internet 
and  shares  information  with  other  LMS  to  distribute  routing  information. 
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2.    Temporally  Ordered  Routing  Algorithm  (TORA) 

The  Temporally-Ordered  Routing  Algorithm  (TORA)  was  developed  by  Park  and 
Corson  and  is  presented  in  detail  in  a  1997  draft  RFC  [8].  It  is  a  source-initiated,  on- 
demand  routing  protocol  proposed  for  dynamic  mobile,  multihop  wireless  networks. 
TORA  is  an  adaptive,  efficient,  and  scaleable  distributed  routing  algorithm  based  on  the 
concept  of  link  reversal.  The  main  feature  of  this  protocol  is  the  ability  to  localize  control 
messages  in  a  very  small  set  of  nodes  which  must  respond  to  a  change  in  network  status, 
such  as  a  link  failure.  This  is  accomplished  by  each  node  maintaining  an  extensive 
routing  cache.  The  cache  memory  leads  to  scalability  problems  in  large  networks  when 
memory  requirements  become  excessive.  The  protocol  is  designed  to  work  on  top  of  the 
MAC  layer  that  handles  link  status,  packet  delivery,  link  and  network  layer  address 
resolution,  and  security  authentication  [8]. 

In  TORA,  the  source  node  initiates  the  route  creation  since  it  is  an  on-demand 
routing  protocol.  The  algorithm  looks  to  build  a  directed  acyclic  graph  (DAG) 
representing  the  relative  heights  of  the  routers  with  reference  to  the  destination.  Routers 
that  are  closer  to  the  destination  have  a  low  height  and  are  referred  to  as  downstream 
nodes.  Routers  that  are  farther  away  from  the  destination  typically  have  ever-increasing 
heights  and  are  referred  to  as  upstream  nodes.  Figure  5  presents  an  illustration  of  a 
directed  acyclic  graph  formed  when  creating  routes  by  relative  heights  of  routers  [9].  The 
height  metric  is  maintained  by  an  ordered  quintuple  (T,  oid,  r,  5,  i) ,  where  x  is  the  logical 
time  of  a  link  failure  defining  a  new  reference  level,  oid  is  the  unique  ID  of  the  router  that 
defined  the  new  reference  level,  r  is  a  reflection  indicator  bit,  5  is  a  propagation  ordering 
parameter,  and  i  is  the  unique  ID  of  the  router  [8]. 
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Figure  5.  TORA  Route  Creation  (From  Ref.  [9]). 


C.         EVALUATION  OF  MANET  PROTOCOLS 


There  is  no  standard  for  evaluating  MANET  protocols.  The  IETF  MANET 
Working  Group  recommends  focusing  on  the  fundamental  tenets  of  MANET  [2]. 
MANETs  exhibit  ad  hoc  behavior  across  the  board.  Bit  rates,  time  constraints,  reliability 
requirements/QoS,  infrastructure,  mobility  patterns,  and  mobility  characteristics  (speed, 
predictability,  and  uniform)  are  all  ad  hoc  in  nature  [3].  Evaluation  is  even  more 
challenging  when  one  considers  that  mobile  wireless  assets  will  have  limited  range, 
packet  loss,  mobility  loss,  limited  power,  frequent  network  partitions,  and  security 
vulnerability. 


The  MANET  Working  Group  emphasizes  that  each  MANET  Routing  Protocol  is 
well  suited  for  particular  MANET  environments,  and  less  suited  for  others.  Each 
protocol  should  be  evaluated  in  terms  of  advantages  and  disadvantages  as  opposed  to  one 
common  test  for  all  protocols  [2].  The  Working  Group  identifies  eight  networking 
environment  variables  for  examination:  network  size,  network  connectivity,  topological 
rate  of  change,  link  capacity,  fraction  of  unidirectional  links,  traffic  patterns,  mobility, 
and  fraction  and  frequency  of  sleeping  modes.  Placing  emphasis  on  intricate  protocol 
comparisons  is  of  limited  value  [7].  The  results  are  often  imprecise  and  make  it  difficult 
to  compare  algorithms  with  vastly  different  functionality  in  a  precise,  fair,  and 
meaningful  fashion.  What  is  important  is  the  average  performance,  which  is  only 
obtained  through  simulation. 

Metrics  utilized  for  evaluation  should  be  independent  of  the  network  protocol  and 
both  qualitative  and  quantitative.  The  Working  Group  identifies  the  following  qualitative 
metrics:  distributed  operation,  loop  freedom,  demand-based  operation,  proactive 
operation,  security,  sleep  period  operation,  and  unidirectional  link  support.  Quantitative 
metrics  identified  are  the  following:  end-to-end  data  throughput,  delay,  route  acquisition 
time,  percentage  of  out-of-order  delivery,  efficiency,  average  number  of  data  bits 
transmitted  divided  by  data  bits  delivered,  average  number  of  control  bits  transmitted/data 
bit,  and  average  number  of  control  and  data  packets  transmitted  divided  by  data  packets 
delivered. 

The  most  important  factor  affecting  performance  is  how  well  the  propagation  of 
redundant  copies  of  a  route  discovery  request  by  a  mobile  can  be  reduced  to  conserve 
memory  cache  [10].  An  algorithm  should  recognize  and  discard  identical  requests  and  if 
a  request  has  identified  a  route  beyond  a  maximum  length.  The  maximum  length 
restriction  serves  to  prevent  infinite  loops  from  occurring  during  discovery.  However, 
aggressive  route  cache  to  enhance  routing  tables  and  the  use  of  cache  are  critical 
parameters  which  prevent  latency  and  unnecessary  queries. 
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III.  ZONE  ROUTING  PROTOCOL  (ZRP) 

The  ZRP  protocol,  developed  by  Haas  and  Pearlman  [11],  incorporates  a  localized 
zone  approach  to  routing.  The  fundamental  approach  is  to  incorporate  a  hybrid  protocol 
that  exploits  the  benefits  of  both  a  reactive  and  a  proactive  protocol  [12].  As  depicted  in 
Figure  6,  each  mobile  node  has  a  proactive  routing  zone  around  it  that  is  dictated  by  an 
adjustable  zone  routing  radius.  The  zone  routing  radius  is  directly  related  to  hop  counts 
from  the  node.  In  Figure  6,  nodes  D,  C,  F,  B,  and  E  are  in  Zone  A  with  zone  routing 
radius  p  =  2.  Routes  outside  the  zone  are  determined  by  an  on-demand  protocol  query 
which  bordercasts  the  out  of  zone  query  to  the  peripheral  nodes  (D,  F,  and  E),  which  in 
turn,  leverage  the  zone  structure  of  the  network  to  reduce  query  detection  time.  The  intent 
behind  this  MANET  routing  approach  is  to  utilize  the  routing  knowledge  in  a  localized 
region  and  obtain  a  route  to  a  distant  node  on-demand.  The  following  discussion  on  ZRP 
will  focus  on  three  major  areas:  Intrazone  Routing  Protocol  (IARP),  Interzone  Routing 
Protocol  (IERP),  and  routing  optimization. 


Circles  depict 
transmit  radius 
of  mobile  node 


Node  H  and  I  form  a  Network  Partition 


Nodes  D,C,F,B,and  E 
are  in  Zone  A 


Nodes  D,  E,  and  Fare 
Peripheral  Nodes  since 
they  are  two  hops  from 
Node  A 


Figure  6.  ZRP  Example  With  Zone  Routing  Radius  p  =  2. 


A.    INTRAZONE  ROUTING  PROTOCOL  (IARP) 


IARP  is  responsible  for  maintaining  routes  within  each  node's  routing  zone 
through  periodic  routing  table  updates.  This  is  usually  accomplished  using  a  wide  range 
of  traditional  distance  vector  or  link-state  protocols  [3].    All  nodes  less  than  or  equal  to 
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the  routing  zone  radius  are  considered  to  be  in  the  zone.  These  nodes  are  referred  to  as 
interior  nodes.  Nodes  on  the  edge  of  the  routing  zone  (those  with  hop  count  equal  to  the 
zone  radius)  are  considered  peripheral  nodes  and  take  on  greater  significance  in  the  next 
section.  Figure  6  depicts  a  typical  zone  centered  around  Node  A  with  p  =  2.  The 
peripheral  nodes  reside  at  the  outermost  limit  of  the  zone  radius.  In  this  case,  D,  F,  and  E 
are  examples  of  peripheral  nodes. 

Regardless  of  the  reactive  protocol  chosen,  it  needs  to  be  modified  to  keep  the 
proactive  traffic  generation  within  the  region  of  an  individual  node's  routing  zone.  For 
example,  a  split  horizon  version  of  the  Distance-Vector  Algorithm  can  be  utilized  for 
IARP.  Although  there  are  tradeoffs  involved  in  IARP  protocol  selection,  experience  has 
shown  that  the  overall  performance  of  ZRP  is  not  affected  by  this  choice  [4].  As  shown 
in  Figure  7,  IARP  relies  on  the  Neighbor  Discovery/Maintenance  Protocol  (NDM)  to 
provide  current  status  of  a  node's  neighbors.  This  NDM  service  is  provided  by  the 
MAC/link-layer  protocols.  Overhead  is  not  spared  in  the  region  for  the  sake  of  proactive 
discovery.  Routing  within  each  region  should  be  fairly  routine  and  not  require  much 
discovery  effort  outside  of  the  proactive  efforts.  The  overhead  generated  with  this 
scheme  is  a  function  of  the  number  of  nodes  in  the  routing  zone  (node  density)  and  the 
zone  routing  radius  [12].  Node  density  is  a  function  of  transmit  radius. 
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Figure  7.  ZRP  Architecture  (After  Ref.  [11]). 
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It  is  important  to  remember  that  the  wireless  nature  of  MANET  can  cause  high 
zone  populations  despite  a  small  hop  count.  As  mentioned  above,  the  physical  coverage 
of  the  transmit  antenna  and  the  receiver  density  (per  unit  area)  dictate  the  number  of 
nodes  in  the  zone  (node  density).  The  result  is  a  significant  increase  in  proactive  IARP 
traffic  and  increased  contention  within  the  local  zone  [4].  Each  MANET  environment  is 
characterized  by  the  number  of  nodes  N,  node  density  8,  and  relative  node  velocity  v. 
The  routing  zone  radius  p  ranges  from  the  reactive  region  (p  =  0)  to  the  proactive  region 
(p— »°°).  The  amount  of  IARP  traffic  per  node  (Tiarp)  can  be  expressed  by 

TiARP  =  V  X  UiARP  /  Neighbor 

where  Uiarp  is  the  number  of  IARP  updates  and  Neighbor  is  the  number  of  neighbors  per 
node  [4].  The  amount  of  IARP  traffic  per  node  does  not  depend  on  the  total  node 
population,  but  it  is  a  function  of  the  the  size  of  p.  Nnejghbor  is  a  function  of  both  p  and  8 
[14]. 

B.         INTERZONE  ROUTING  PROTOCOL  (IERP) 

Routing  outside  the  zone  is  done  based  on  a  reactive  or  on-demand  approach,  by 
using  IERP.  Some  of  the  functions  of  IERP  including  bordercasting,  route  accumulation, 
and  query  control,  are  performed  by  a  special  component  of  IERP  called  the  Bordercast 
Resolution  Protocol  (BRP)  (see  Figure  7).  IERP  queries  through  the  network,  although 
global  in  nature,  are  expedited  through  the  use  of  proactive  routing  zones.  Instead  of 
having  to  reach  each  node,  the  discovery  process  must  merely  touch  each  routing  zone  to 
discover  the  targeted  node.  When  IERP  queries  are  compared  to  a  flooding  mechanism, 
efficiency  is  increased  and  overhead  is  decreased  by  utilizing  the  zone  topology  of  the 
network.  The  number  of  nodes  queried  (Nq)  in  the  MANET  is  on  the  order  of  (d) 

Nq  ~  0  (pzone/pnet)2 

where  pzone  is  the  zone  routing  radius  and  pnet  is  the  network  radius  [13]. 

The  amount  of  route  usage  will  vary  due  to  applications  and  is  expressed  by  two 
independent  parameters:  Rinitiai-query  and  Rr0ute-usage  [4].  Route  stability  is  dictated  by  route 
lengths  and  is  a  factor  of  the  span  of  the  network,  node  velocity  v,  node  density  8,  and 
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zone  radius  p.  Stability  is  expressed  in  terms  of  lifetime  and  is  represented  by  its  inverse, 
the  average  route  failure  (Rroute-faiiure)-  The  amount  of  IERP  traffic  (TERp)  is  represented 
by 

TlERP  =  TqN  (p,  5)  X  TqUery 

—  AqN  \yy  O)  X  rS  X  y  IMnitial-qtiery  "■"  Ksubsequent-queriey) 

where  Tquery  is  the  rate  of  traffic  queries,  N  is  the  number  of  network  nodes,  and  TqN  is 
traffic  per  queries  per  node  and  is  a  function  of  p  and  5  [4]. 

Routing  failures  are  detected  and  repaired  reactively  by  IERP.  However,  route 
failures  can  be  detected  by  IP  when  a  source  route  is  determined  to  be  unreachable.  As 
shown  in  Figure  7,  a  route  failure  notification  is  usually  provided  by  protocols,  such  as 
the  Internet  Control  Message  Protocol  (ICMP).  The  repair  process  initiated  by  IERP  is 
almost  identical  to  the  discovery  process.  IARP  utilizes  proactive  route  failure  detection, 
which  is  triggered  in  response  to  a  node  leaving  the  source  node's  zone  by  the  NDM 
mechanism. 

1.  Border  Routing  Protocol  (BRP) 

Before  examining  the  routing  process,  it  is  important  to  understand  the  structure 
of  the  localized  nodes  and  the  concept  of  bordercasting.  As  depicted  in  Figure  7,  BRP  is 
a  subset  and  the  workhorse  of  IERP.  It  provides  bordercasting,  route  accumulation,  route 
optimization,  and  query  control  [14].  As  stated  earlier,  each  zone  is  centered  on  a  node 
and  the  size  is  dictated  by  the  radius  which  can  be  modified  for  efficient  routing  in 
various  types  of  networks  [4].  When  a  node  must  reach  a  destination  outside  of  the  zone, 
efficiency  is  increased  by  bordercasting  the  query  request  directly  to  the  peripheral  nodes 
to  reach  the  entire  network.  BRP  uses  efficient  flooding  (multipoint  relay)  and  efficient 
probing  to  control  unnecessary  overhead.  It  also  does  proactive  route  repair  and  route 
shortening  to  improve  performance.  This  reduces  the  overhead  in  comparison  to  simple 
flooding  over  the  entire  network.  IERP  provides  the  route  retrieval  and  route  failure 
functions  once  the  route  is  identified. 

Due  to  the  extensive  proactive  discovery  of  IARP,  a  node  can  efficiently  reach 
another  node  within  the  zone.  As  mentioned  above,  BRP  provides  the  route  optimization 
inside  each  zone  [14].  When  a  node  must  be  reached  outside  of  the  zone,  this  process  is 
made  more  efficient  by  now  exploiting  the  zonal  topology  of  the  network.   With  a  quick 
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table  look  up,  the  node  is  able  to  first  determine  if  the  destination  is  within  the  node's 
zone.  Once  this  factor  is  eliminated,  the  query  is  quickly  bordercasted  to  the  peripheral 
nodes  to  initiate  the  broader  search.  The  peripheral  nodes'  neighbors  cast  to  their 
respective  neighbors  not  in  the  region,  and  each  neighbor  node  is  able  to  quickly 
determine  if  the  prospective  destination  node  is  within  its  zone.  If  not  found  in  the 
neighbor  zone,  the  neighbor  nodes  in  turn  will  bordercast  across  their  zones,  and  the 
process  continues  until  the  destination  node  is  located.  Once  the  destination  node  is 
located,  IERP  returns  the  requested  route  to  the  source  node  which  has  been  optimized 
by  BRP  using  the  proactive  routing  information  stored  in  each  zone  by  IARP. 

Figure  8  illustrates  the  discovery  process  used  in  IERP.  Node  A  has  a  datagram 
to  send  to  L.  As  depicted,  L  is  not  in  A's  routing  zone.  Node  A  bordercasts  (BRP)  the 
route  query  to  all  peripheral  nodes  (D,  E,  F,  and  G).  Each  peripheral  node,  in  turn,  checks 
its  routing  table  (IARP)  for  L  and  none  of  them  have  it.  Each  peripheral  node  now 
bordercasts  (BRP)  to  its  own  peripheral  nodes.  For  example,  Node  G  conducts  a  table 
look  up  from  its  zone  table  (IARP)  and  is  unable  to  locate  node  L.  A  bordercast  (BRP)  is 
initiated  by  node  G,  and  K  is  able  to  check  its  table  (IARP)  and  quickly  respond  (IERP) 
with  the  location  of  node  L.  The  return  route  is  identical  to  the  query  route. 


ZONE  A 


DEST 


Figure  8.  IERP  Search  with  BRP  (From  Ref.  [11]). 


ZRP  does  incorporate  a  query  detection  mechanism  to  reduce  redundant  queries 
and  prevent  it  from  degenerating  to  a  flooding  protocol  [4].  ZRP  offers  two  distinct 
methods  of  query  detection  for  redundant  queries  and  reduce  overhead.  Query  Detection 
1  (QD1)  allows  the  intermediate  nodes  to  detect  a  redundant  query  and  terminate  the 

15 


thread.     Query  Detection  2  (QD2)  allows  all  nodes  to  detect  a  redundant  query  and 
terminate  the  request. 

C.         ROUTING  ZONE  OPTIMIZATION 

A  mathematical  expression  for  the  optimum  zone  radius  for  optimum 
performance  has  not  yet  been  determined  [4].  Even  with  perfect  knowledge  of  all 
network  parameters,  computation  of  an  optimal  routing  zone  radius  is  not  a 
straightforward  mechanism.  Haas  [4]  recommends  that  further  research  could  focus  on  a 
complete  derivation  of  the  ZRP  traffic  function.  As  depicted  in  Figure  9,  a  simple 
approach  is  to  adjust  the  zone  routing  radius  until  the  setting  for  minimum  ZRP  overhead 
traffic  is  achieved.  In  the  interim,  two  other  schemes  have  been  suggested  for  optimum 
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Figure  9.  ZRP  Zone  Routing  Radius  Optimization. 


zone  routing  radius  selection:  min-searching  and  traffic  adaptive  method  [4].  Min- 
searching  assumes  that  the  node  behavior  will  not  change  quickly  over  a  period  of  time 
and  an  accurate  assessment  of  ZRP  traffic  can  be  obtained.  As  shown  in  Figure  9,  if 
IERP  traffic  is  decreasing  and  the  amount  of  proactive  IARP  traffic  is  increasing,  there  is 
an  "undershoot"  of  the  optimum  zone  radius.  Likewise,  if  IERP  traffic  is  increasing  and 
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IARP  traffic  is  also  increasing  would  indicate  an  "overshoot"  of  the  optimum  zone  radius. 
The  traffic  adaptive  method  only  relies  on  current  estimates.  In  this  case,  Haas  [4]  has 
shown  that  the  amount  of  ZRP  traffic  generated  is  significantly  higher  when  the  ZRP 
traffic  is  dominated  by  the  reactive  IERP  query  traffic.  The  same  is  true  when  IARP 
traffic  dominates.  As  depicted  in  Figure  9,  the  optimum  region  resides  between  these  two 
regions.  In  other  words,  the  ratio  between  ERP  to  IARP  (EERP/IARP)  should  be  as  close 
one  as  possible  for  optimization.  The  general  rule-of-thumb  is  that  a  sparse  network 
favors  a  large  routing  zone  and  a  dense  network  favors  a  small  routing  zone. 

D.        SUMMARY 

Chapter  lH  has  presented  the  ZRP  protocol  and  the  three  main  component 
protocols:  IARP,  IERP,  and  BRP.  ZRP  establishes  a  routing  zone  around  each  node  in 
the  MANET  environment.  The  size  of  each  routing  zone  is  dictated  by  an  adjustable 
zone  routing  radius.  Within  each  routing  zone,  IARP  is  responsible  for  maintaining 
routes  through  periodic  routing  table  updates.  All  nodes  less  than  or  equal  to  the  routing 
zone  radius  are  considered  in  the  zone.  Routing  outside  the  zone  is  done  using  a  reactive 
on-demand  protocol,  IERP.  BRP,  a  subset  of  IERP,  provides  bordercasting,  route 
accumulation,  and  query  control.  IERP  queries  outside  the  zone  are  propagated  by  the 
use  of  the  proactive  routing  zones  defined  in  the  MANET.  ZRP  optimization  is  achieved 
by  balancing  IERP  and  IARP  overhead  traffic.  The  optimum  zone  routing  radius  resides 
in  the  region  where  the  ratio  between  IARP  and  IERP  overhead  is  equal  to  one.  The  min- 
searching  and  traffic  adaptive  method  are  two  alternative  techniques  for  locating  the 
optimum  zone  routing  radius. 
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IV.  SIMULATION 

The  simulation  software  used  in  this  thesis  was  OPNET,  Version  7.0  on  a 
Windows  NT  platform.  Pearlman's  ZRP  OPNET  implementation,  developed  in  a  UNIX 
environment,  was  the  only  MANET  protocol  available  at  the  time  of  this  work  and  was 
made  available  to  the  author.  The  UNIX  based  model  was  modified  by  the  author 
through  extensive  collaboration  with  Pearlman  [14]  for  implementation  into  a  Windows 
NT  environment.  The  OPNET  package  was  chosen  for  this  MANET  protocol  research 
due  to  its  availability  at  the  Naval  Postgraduate  School  (NPS).  Other  popular  simulation 
software  packages  used  for  MANET  protocol  simulation  include  ns2,  PARSEC,  and  the 
C  programming  language. 

A.         OPTIMUM  NETWORK  PERFORMANCE  (OPNET) 

OPNET  Version  7.0  can  be  used  to  simulate  most  standard  network  protocols  and 
IEEE  standards.  For  example,  this  most  recent  version  has  the  ability  to  simulate  IEEE 
802.11  for  wireless  networks.  There  is  an  extensive  model  library  with  easy  to  follow 
instructions  and  examples.  However,  MANET  protocols  are  not  yet  standard  with 
OPNET.  The  models  can  be  broken  down  into  three  distinct  levels  as  depicted  in  Figure 
10.  The  network  layer  depicts  the  network  objects  needed  for  network  implementation. 
Each  element  (e.g.,  computer,  bridge,  router)  in  the  network  model  is  composed  of  a  node 
model,  which  is  further  subdivided  into  node  objects.  For  example,  in  Figure  10,  udp, 
rsvp,  ip_encap,  and  application  are  node  objects  of  the  workstation  node  model.  The 
node  object  behavior  is  modeled  by  process  models  which  actually  contain  the  C  code 
and  OPNET  specific  kernel  procedures. 

The  C  code  and  kernel  procedures  in  an  OPNET  simulation  are  only  executed  in 
three  locations  which  all  reside  in  the  process  model  states.  As  depicted  in  Figure  10,  a 
stop  sign-like  icon  represents  a  wait  state.  There  are  three  types  of  states:  initial, 
unforced,  and  transitional.  The  initial  and  unforced  states  appear  as  red  stop  signs  and  the 
transitional  state  appears  as  a  green  stop  sign.  Transitions  form  the  connections  between 
states.  Within  the  stop  signs,  there  are  Enter  Execs  and  Exit  Execs  where  code  is 
executed.  As  shown  in  Figure  10,  the  Exit  Execs  of  the  wait  state  appear  in  the  lower 
right  hand  window.  An  unforced  state  will  execute  the  Enter  Execs  code  and  return 
control  to  the  processor  while  awaiting  for  a  transition  condition.  Simulation  time  only 
expires  between  unforced  states  and  processor  handoffs.  If  a  transition  is  identified  in  the 
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form  of  a  code  interrupt,  transition  code  will  be  executed  by  the  green  transition  states  or 
by  code  resident  in  the  transition  link  itself.  For  example,  in  Figure  10,  a  default 
transition  condition  forces  a  return  to  the  wait  state  in  the  event  of  an  unpredicted 
condition. 
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Figure  10.  OPNET  Simulation  Methodology  From  Ref.  [15]. 

B.         ZRP  MODEL 

The  ZRP  OPNET  model  is  implemented  by  placing  individual  MANET  mobile 
ZRP  network  objects,  called  manet_ls,  in  the  workspace  to  create  a  network  model. 
Figure  1 1  depicts  a  typical  network  model  configuration  manet_ls  of  network  objects 
positioned  in  a  workspace.  Each  manetjs  has  behavior  driven  by  the  node  model.  The 
manet_ls  node  model  is  depicted  in  Figure  12  and  illustrates  the  various  node  objects 
required  to  implement  manet_ls:  routing  (routing),  movement  (move),  transceiver 
(tx_simple  and  rx_simple),  MAC  (delivery  and  beacon),  and  traffic  generation  (app).  The 
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node  objects  of  manetjis  are  explained  in  further  detail  in  the  following  sections.  The 
number  of  manetjs  ZRP  nodes  in  the  network  model  is  limited  to  approximately  1000 
[14].  The  user  is  able  to  manipulate  the  following  variables  for  each  simulation:  zone 
routing  radius  p  in  hop  count,  node  velocity  v  in  km/sec,  transmit  radius  tr  in  km,  and  the 
duration  of  simulation  (time  units  as  appropriate).  The  node  movement  field  is  two 
dimensional  and  defined  by  an  x_axis  and  y_axis  entry  (km). 
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Figure  1 1 .  ZRP  Network  Configuration. 

1.  Routing  and  Traffic  Generation 

As  depicted  in  Figure  12,  the  routing  node  object  is  the  key  to  the  ZRP  model's 
routing  performance.  From  routing,  the  traffic  is  passed  to  the  appropriate-routing 
protocol  for  processing  as  explained  in  Chapter  EI.  IARP  handles  the  in-zone  traffic. 
IERP  and  BRP  handle  the  out-of-zone  traffic.  Figure  13  is  provided  to  illustrate  the  node 
object,  routing,  within  manetjis.  In  this  depiction,  a  query  packet  has  arrived  at  routing 
after  being  routed  to  IARP  (see  Figure  14)  to  determine  if  the  destination  node  was 
located  in  the  source  node's  routing  zone.  The  destination  node  was  not  located  in  the 
routing  zone  so  the  routing  mechanism  passes  the  query  packet  to  BRP  (see  Figure  15) 
for   bordercasting    which    interacts    with    IERP    (see    Figure    16)    to    provide    route 
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accumulation  until  the  destination  node  is  located.  IERP  provides  the  route  reply 
notification  to  the  source  node.  As  the  process  model  executes  through  the  xmit  transition 
state,  the  Enter  Exec  code  depicted  is  executed,  which  records  the  amount  of  overhead 
traffic  being  generated  to  meet  the  query  requirement. 
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Figure  12.  Manet_ls  Node  Model. 


The  beacon  module  is  part  of  a  neighbor  discovery  action  which  is  typical  of  most 
MAC  protocols  and  independent  of  ZRP  [4].  The  MAC  neighbor  discovery  components, 
beacon  and  delivery,  shown  in  Figure  12,  were  purposely  included  in  manetjis  to  provide 
an  ideal  MAC  behavior  for  comparison  with  various  MAC  protocols.    The  MAC  layer 
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provides  ideal  scheduling  of  packet  transmissions  to  avoid  collisions.  This  feature  allows 
for  delays  produced  by  various  MAC  protocols  to  be  isolated.  It  has  been  shown  that  the 
MAC  protocol  has  little  effect  on  the  overall  performance  of  ZRP  [4].  The  IARP  traffic 
is  generated  based  on  a  change  in  a  neighbors  status  which  is  updated  every  2Tbeacon  (0.5 
seconds)  for  link  status.  The  amount  of  IARP  traffic  is  independent  of  the  total  network 
population  and  dictated  by  node  density  and  the  zone  routing  radius.  IERP  traffic  is 
distributed  on  a  uniform  random  traffic  queries  initiated  by  the  app  process  model. 
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Figure  13.  Depiction  of  Routing  Node  Object  Within  ZRP_Manager. 


23 


Figure  14.  IARP  Process  Model. 
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Figure  15.  BRP  Process  Model. 
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Figure  16.  IERP  Process  Model. 


The  simulation  traffic  is  controlled  by  the  model  attributes  of  the  app  process 
model  depicted  in  Figure  17.  The  number  of  total  sessions  (transmissions  per 
simulation),  packets  per  session,  session  interarrival  delay,  packet  interarrival  delay, 
mode  (transceiver  pipeline  model),  and  destination,  are  manipulated  from  this  window. 
The  destination  of  each  session  (transmission)  is  usually  set  using  a  uniform  random 
variable  for  delivery  throughout  the  network.  A  single  session  can  be  setup  between  two 
nodes  if  the  time  to  execute  a  single  session  exceeds  the  simulation  time.  This  is 
accomplished  by  increasing  the  packets  per  session  until  time  of  delivery  exceeds  the 
simulation  time.  The  simulation  is  interrupted  before  another  session  with  a  MANET 
node  is  initiated.  This  traffic  channel  analysis  is  only  beneficial  when  using  complex 
transceiver  pipeline  modeling  which  will  be  explained  in  the  following  section. 
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Figure  17.  APP  Process  Model  and  Attribute  Window. 


2.  LINK  ESTABLISHMENT 


OPNET  simulates  communication  between  two  nodes  through  a  process  known  as 
the  transceiver  pipeline.  The  transceiver  pipeline  models  the  transmission  of  packets 
across  a  communications  channel  (link).  The  OPNET  package  factors  in  the  MAC  layer 
attributes  and  includes  multiple  stages  to  model  the  channel's  behavior.  Both  the  radio 
transmitter  and  radio  receiver  node  objects  (tx_simple  and  rx_simple  in  Figure  12)  include 
the  following  transceiver  pipeline  attributes:  transmission  delay,  link  closure  (LOS), 
channel  match,  transmitter  antenna  gain,  propagation  delay,  receiver  antenna  gain, 
received  power,  background  noise,  interference  noise,  signal-to-noise  ratio  (SNR),  bit 
error  rate  (BER),  error  allocation,  and  error  correction. 

The  complexity  of  the  transceiver  pipeline  was  intentionally  bypassed  in  the 
current  model  to  simplify  the  communication  simulation  between  ZRP  MANET  nodes 
[14].  Each  mobile  node  utilizes  a  transmitter  and  receiver  in  direct  delivery  mode.  The 
direct  delivery  attribute  bypasses  the  transceiver  pipeline  options  resident  in  OPNET  and 
provides  error  free  delivery  to  the  destination  node.  Packet  delivery  fails  only  if  a  node 
moves  out  of  range.  An  error  free  transceiver  pipeline  is  assured  if  a  destination  node 
falls  physically  within  the  source  node's  transmitter  radius.  The  delivery  node  object 
handles  this  process  through  the  tx_simple  and  rx_simple  node  objects  depicted  in  Figure 
12.     The  simple  implementation  of  tx_default  and  rx_default  alone  does  not  enable 
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OPNET  transceiver  pipeline  modeling.  It  was  determined  by  the  author  that  further  code 
and  model  modifications  are  necessary  to  interface  with  the  transceiver  pipeline  model 
mechanisms.  As  explained  above,  with  code  and  OPNET  model  changes,  more  complex 
link  analysis  could  be  used  to  create  ad  hoc  transceiver  pipeline  and  traffic  generation. 

Inside  the  delivery  node  object,  a  packet _delivery  process  model  provides  the 
ideal  MAC  for  the  ZRP  model  [14].  The  beacon  module  was  specifically  written  for  this 
simulation  and  handles  neighbor  discovery  in  a  manner  similar  to  most  MAC  protocols. 
The  bits  transmitted  by  the  beacon  module  are  not  counted  as  overhead  against  the  ZRP 
protocol  since  the  MAC  layer  is  present  regardless  of  the  protocol  instituted.  The 
tx_default  and  rx_default  allow  for  future  interaction  with  OPNET  transceiver  pipeline 
modeling.  The  channel  attribute  setting  in  both  tx_default  and  rx_default  can  be 
manipulated  to  set  data  pipeline  size.  Due  to  an  undetermined  coding  error  in  the  ZRP 
model,  10  Mbps  was  used  as  the  default  channel  rate.  Troubleshooting  indicated  a 
pointer  error  caused  by  the  function  call,  update_Detected_Queries_Table,  which  is 
depicted  in  Figure  18.  The  function  call  resides  in  IERP  and  is  located  in  the  Enter  Execs 
of  update jrequest.  The  corrective  action  taken  was  to  comment  the  code  out  during 
execution  and  this  was  determined  to  not  impact  the  model  results  with  a  10  Mbps 
channel  rate. 
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Figure  18.  Pointer  Error  Correction  to  IERP  Process  Model. 

3.  NODE  MOVEMENT 

Node  movement  is  simulated  by  the  move  node  object  depicted  in  Figure  12.  As 
mentioned  above,  the  user  is  able  to  input  a  uniform  velocity  in  km/sec  for  all  the 
MANET  nodes  from  the  simulation  attribute  window.  At  t  =  0  sec,  each  node  heads  off 
on  a  direction  assigned  by  a  uniform  random  variable,  in  the  range  [0-2tt],  invoked  by 
move.  If  a  node  impacts  the  edge  of  the  virtual  xy  plane,  it  is  detected  by  a  transition 
condition  in  the  move  process  model,  a  direction  is  recomputed  in  the  range  [0-27t],  and 
the  mobile  node  continues  to  move  about  the  virtual  x-y  plane.  The  animation  attributes 
of  OPNET  depicting  this  random  movement  by  selecting  record  animation  from  the 
project  editor  menu.  A  viewer  window,  m3_vuanim,  can  be  deployed  by  selecting  play 
animation  following  the  execution  of  a  simulation  to  view  the  random  node  movements. 
M3_vuanim  uses  a  tape  recorder  like  interface  that  can  be  manipulated  to  control  the 
speed  of  node  movements. 
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4.  STATISTICS  PRODUCTION 

Due  to  the  cumbersome  statistic  collection  methods  of  earlier  versions  of  OPNET, 
a  standard  C  code  export  file  command,  fprintf,  was  used  in  the  ZRP  model  to  collect 
statistics  for  analysis  [14].  As  the  code  executes,  standard  *.dat  files  are  produced  in  the 
OPNET  bin  folder  at  the  conclusion  of  each  simulation.  As  explained  earlier,  although 
OPNET  has  inherent  statistical  collection,  the  standard  node  objects  were  not  utilized 
throughout  the  ZRP  model,  so  there  is  no  connection  with  the  inherent  statistical 
collection  of  OPNET.  The  technique  employed  by  the  ZRP  model  is  to  use  static 
variables  declared  in  the  process  model  code  to  provide  the  basis  to  gather  statistics.  The 
various  process  models  have  END_SIM  states,  which  gather  statistics  during  each  process 
model  execution  call  by  the  ZRP  model.  Figure  19  depicts  the  app  process  model  which 
contains  the  END_SIM  state  for  statistic  production.  This  information  traffic  meter  was 
added  to  the  latest  ZRP  version  to  provide  visibility  to  data  throughput  and  efficiency 
[14].  The  kevin_stat2  meter  measured  sessions_sent,  sessionsjrcvd,  packets _sent, 
packets_rcvd,  bits_sent,  bitsjrcvd,  total  packet  delay,  and  total  jitter.  MATLAB  was 
utilized  to  organize  collected  data  and  produce  results  for  analysis.  Previous  work  on  the 
ZRP  model  focused  on  ZRP  overhead  and  had  elected  to  neglect  the  traffic  parameters 
[14]. 
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Figure  19.  Example  Of  END_SM  Statistical  Collection. 


C.         SUMMARY 


This  chapter  has  provided  an  introduction  to  OPNET  Version  7.0  and  presented 
the  ZRP  model  which  was  converted  to  Windows  NT  from  a  UNIX  implementation. 
OPNET  uses  the  concept  of  workspace,  network  models,  node  models,  node  objects,  and 
process  models  for  network  simulation.  The  behavior  of  mobile  nodes  using  the  ZRP 
protocol  in  a  MANET  environment  is  executed  through  the  manet_ls  node  model. 
Routing  routes  traffic  queries  generated  by  the  app  process  model  to  the  appropriate 
IARP,  IERP,  and  BRP  process.  Traffic  delivery  between  nodes  is  ensured  during  each 
session  (transmission)  through  the  use  of  the  direct  delivery  mode.  Source  traffic  volume 
can  be  adjusted  through  the  app  attribute  window.  Move  provides  random  movement  and 
constant  velocity  to  each  node  over  the  course  of  the  simulation.  Statistics  were 
collected  on  each  simulation  through  the  use  of  the  fprintf  command  executed  in  the 
END_SIM  states  of  various  process  models  and  analyzed  in  MATLAB.  A  source  traffic 
meter  was  added  to  the  ZRP  model  for  routing  efficiency  analysis. 
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V.  RESULTS 

In  this  chapter,  the  results  of  the  ZRP  OPNET  simulations  with  the  Marine 
scenario  are  analyzed.  The  focus  of  this  analysis  was  to  evaluate  the  efficiency  and 
reliability  performance  of  the  protocol.  As  discussed  in  Chapter  IV,  due  to  the  hardware 
limitations  of  the  Windows  NT  platform,  experimentation  was  required  to  determine 
simulation  parameters  which  could  be  evaluated  within  hardware  constraints.  Section  A 
explains  the  scenario  and  configuration  development  process  to  meet  these  limitations. 
Previous  research  results  from  Hass  and  Pearlman  [4]  are  utilized  to  provide  a 
comparison  with  the  results  from  this  work  and  also  illustrate  ZRP  behavior  which  could 
not  be  demonstrated  with  the  Marine  scenario.  The  traffic  overhead  generated  by  ZRP  is 
presented  in  Section  B  by  component  (LARP,  IERP,  and  BRP)  to  better  understand  the 
contribution  from  each  sub-protocol  which  shapes  the  behavior  and  efficiency  in  a 
MANET  environment.  The  first  case  examines  ZRP  overhead  with  changing  zone 
routing  radius.  The  second  case  examines  ZRP  overhead  with  changing  velocity.  Section 
C  utilizes  the  same  two  situations  to  study  the  link  performance  of  ZRP  in  the  Marine 
scenario.  This  chapter  concludes  with  an  analysis  of  efficiency  and  routing  optimization. 
Efficiency  is  measured  against  link  performance  to  better  understand  the  tradeoff  between 
routing  overhead  and  link  performance.  Using  the  Marine  scenario  as  a  case  study, 
results  of  the  min-searching  and  traffic  adaptive  methods  of  routing  optimization  are 
presented. 

A.         SCENARIO 

The  network  configuration  used  in  this  scenario  was  designed  to  mirror  the 
tactical  use  of  JTRS  by  individual  Marines.  JTRS  will  provide  the  next  generation  of 
tactical  radios  for  the  warfighter.  The  network  implementation  was  designed  to  emulate  a 
Marine  rifle  platoon  operating  with  a  JTRS  squad-level  radio.  Although  a  Marine  rifle 
platoon  operates  with  forty-two  personnel,  thirty-two  nodes  were  utilized  in  this  work, 
which  provides  a  reasonable  representation  of  this  combat  force.  The  number  of  nodes 
was  kept  to  thirty-two  to  reduce  the  demand  on  the  Windows  NT  platform's  limited 
computing  power  and  to  reduce  simulation  time.  The  32  MANET  nodes,  modeled  by  the 
process  model  manetjs,  represent  individual  Marine  rifleman  with  individual  movement 
and  data  exchange  capabilities.  In  a  rapidly  developing  combat  situation,  each  Marine 
would  transmit  and  receive  information  to  his  fellow  Marines  for  control  and  situation 
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awareness.  As  explained  in  Chapter  IV,  each  MANET  node  moves  individually  across 
the  x-y  plane  and  communicates  in  a  random  fashion  to  mimic  combat  maneuvering  and 
tactical  data  traffic.  It  is  important  to  note  that  due  to  the  limitations  of  the  current  ZRP 
configuration,  the  MANET  nodes  do  not  move  in  tactical  formations.  Each  node  is  an 
independent  random  variable  for  both  movement  and  traffic  placed  on  the  net. 

The  x_axis  and  y_axis  parameters  for  the  simulation  were  configured  to  establish 
a  1  km  x  1  km  x-y  plane  to  represent  an  operational  area  assigned  to  a  rifle  platoon.  As 
depicted  in  Figure  1 1,  the  MANET  nodes  were  placed  in  a  checkerboard  fashion  from  the 
OPNET  network  editor  window.  From  repeated  experimentation  with  simulation 
parameters,  it  was  determined  that  a  1  square-kilometer  x-y  plane  produced  a  node 
density  that  balanced  the  requirement  for  freedom  of  movement  and  mobile  node 
interaction.  As  explained  in  Chapter  IV,  each  MANET  node  moves  at  a  constant  velocity 
in  km  per  second.  However,  a  platoon  will  not  intentionally  disengage  from  each  other 
and  will  seek  to  preserve  their  tactical  formations.  In  order  to  facilitate  this  behavior,  the 
x_axis  and  y_axis  parameters  restricted  movement  to  preserve  unit  integrity,  command 
and  control,  and  combat  power.  Experimentation  further  demonstrated  that  the  1  square- 
kilometer  maneuver  space  served  the  purpose  of  preserving  an  average  node  neighbor 
density  between  3-5  neighbors  during  the  simulation  with  transmit  radius  tr  =  0.2  km,  as 
depicted  in  Figure  20. 


1.5  2  2.5 

Zone  Routing  Radius 


Figure  20.  LARP  Overhead  with  Changing  Zone  Radius  (After  Ref.  [4]). 
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In  order  to  provide  a  model  reference  and  measure  the  amount  of  neighbor  density 
driven  by  the  scenario  at  various  tr  and  p  settings,  the  comparison  between  IARP  traffic 
per  node  and  average  neighbor  density  was  accomplished  by  utilizing  Ref  [4],  which 
measured  the  IARP  packets  per  node  and  related  it  to  neighbor  density.  Neighbor 
density,  the  number  of  MANET  nodes  that  a  source  node  can  reach  in  one  hop,  is 
primarily  a  function  of  transmit  radius.  Neighbors  impact  the  population  of  a  source 
node's  routing  zone  which  dictates  the  amount  of  IARP  traffic.  The  IARP  meter, 
explained  in  Chapter  rv,  provides  the  feedback  on  each  source  node  over  the  course  of 
the  simulation.  From  the  data  produced  from  the  IARP  meter,  Figure  20  was  produced  to 
measure  the  average  neighbors  per  node  and  IARP  traffic  per  node  (packets/sec).  Figure 
20  illustrates  the  Marine  scenario  with  tr  =  0.2  km  and  tr  =  0. 1  km  compared  with  more 
dense  ZRP  simulations  and  larger  x-y  planes.  As  depicted,  tr  =  0.2  km  provided  between 
3  and  5  neighbors  at  zone  routing  radius  of  p  =  1 .  For  p  >  1 ,  the  IARP  traffic  per  node 
approaches  a  peak  of  50  packets/seconds.  This  leveling  effect  is  due  to  the  small  network 
size.  As  the  p  increases,  its  impact  on  the  network  is  limited  due  to  the  small  size  of  the 
network.  With  tr  =  0. 1  km,  the  IARP  traffic  was  reduced  due  to  with  decreased  neighbor 
density  as  a  result  of  a  smaller  transmit  radius.  Simulation  at  tr  =  3  km  proved  to  be 
impractical  for  the  Windows  NT  platform  being  utilized  due  to  exponential  simulation 
time  increases  as  p  was  increased.  As  shown  in  Figure  20,  the  IARP  traffic  increases 
considerably  as  node  density  and  p  are  increased  in  conjunction.  The  data  points  from 
Ref  [4]  in  Figure  20  are  provided  to  illustrate  this  behavior  of  ZRP  in  a  MANET  with  a 
higher  level  of  neighbor  density  that  could  not  be  modeled  due  to  hardware  limitations. 

Figure  21  illustrates  the  random  movement  of  the  nodes  over  the  course  of  a 
typical  simulation.  The  hollow  circles  depict  the  checkerboard  starting  positions 
displayed  in  Figure  11.  At  the  conclusion  of  the  simulation,  the  MANET  node  positions 
are  recorded  by  the  stars.  From  the  final  positions,  clusters  of  nodes  and  network 
partitions  are  clearly  visible.  When  MANET  nodes  cluster,  the  network  is  enhanced 
through  multiple  transmission  routes.  However,  on  the  outer  edges  of  the  network, 
mobile  nodes  lack  network  stability  and  form  a  network  partition  which  is  completely  cut 
off  from  the  rest  of  the  network. 


33 


1 

— 1 — 

I 

1 

1 

T 

■  1 

— r 

I 

T  -   ■ 

0 

start 

0.9 

+ 

* 

finish    - 

0.8 

* 

+ 

0.7 

O 

0 

* 

0 

o 

0 

■ 

0.6 

CO 

+ 

0 

4 

+ 

o    + 

o 

0 

+ 

- 

£0.5 

* 

* 

+ 

>% 

+ 

0 

Q 

o 

0 

0.4 

0 

o 

0 

* 

0 

- 

0.3 

+ 

& 

o 

+ 

o 

+ 

+ 

+ 

Q 

- 

0.2 

O 

o 

$ 

o 

0 

+ 

* 

0.1 

n 

0 

* 

1 

*° 

1 

1 

0 

1 

o 

.1. 

* 

* 

1 

i 

0         0.1        0.2       0.3       0.4       0.5       0.6       0.7       0.8       0.9         1 

x  axis 

Figure  2 1 .  Typical  Scenario  Movement  Results. 


1.  Configuration 


The  ZRP  model  provided  to  the  author  was  developed  using  earlier  versions  of 
OPNET  (Versions  3.5  -  6.0)  in  a  UNIX  environment.  As  a  result,  the  model  had  to  be 
updated  to  OPNET  Version  7.0  and  some  code  changes  had  to  be  made  to  facilitate  the 
implementation  on  a  Windows  NT  platform.  For  instance,  the  variable  M_PI  is  used  by 
UNIX  to  represent  the  constant  7t  and  was  not  recognized  by  the  Microsoft  Visual  C++ 
compiler  linked  with  OPNET  running  on  the  Windows  NT  platform.  The  OPNET  kernel 
procedure  op_mko_all  was  used  to  force  the  conversion  to  Version  7.0.  Multiple  code 
modifications  were  required  to  manipulate  the  ZRP  versions,  code,  and  process  models  to 
achieve  proper  execution  of  the  simulation.  The  most  recent  version  of  the  OPNET  ZRP 
model  was  utilized.  This  included  the  new  IARP  process  model,  IARP_ls,  which 
executes  a  purely  periodic  proactive  routing  protocol. 

As  explained  in  Section  A,  IARP  traffic  is  directly  related  to  node  density  and 
proved  to  be  the  pivotal  barometer  which  established  the  scenario  parameters  that  could 
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be  modeled  on  the  Windows  NT  platform  for  this  analysis.  A  zone  routing  radius  of  p  > 
1,  x_axis  =  1  km,  y_axis  =  1  km,  and  a  transmit  radius  of  tr  <  0.3  km  resulted  in  a 
reasonable  IARP  OPNET  simulation  event  list  requirement  by  tempering  the  neighbor 
density.  Due  to  a  programming  decision,  p  =  0  cannot  be  directly  entered  into  the 
simulation  parameters  of  the  ZRP  model  [14].  The  ZRP  model  implementation  requires  a 
simulation  parameter  of  p  =  1  to  simulate  the  p  =  0  state.  Therefore,  p  settings  must  be 
incremented  by  one  in  simulation  window  entry.  The  next  version  of  ZRP  will  allow  for 
a  p  =  0  entry.  The  neighbor  density  was  determined  to  be  acceptable  at  a  transmit  radius 
tr  <  0.3  km  and  a  simulation  time  of  15  minutes.  The  routing  zone  radius  was  kept  at  p  < 
4  due  to  unreasonable  simulation  times  above  this  threshold.  The  sessions  per 
transmission  (data  transfers  per  transmission)  was  set  to  1  to  decrease  transmission  load. 
Session  interarrival  was  not  a  factor  in  this  case.  Packet  size  is  1,000  bits  and  one  packet 
was  sent  during  each  session  (transmission).  Since  only  one  packet  was  transmitted  per 
session,  packet  interarrival  delay  was  not  modeled.  The  channel  data  rate  was  set  for  a 
default  10  Mbps  due  to  a  memory  error  at  lower  data  rates  (see  Link  Establishment, 
Chapter  IV  for  details).  Based  on  the  simulation  parameters  explained  above  and 
experimentation,  it  was  determined  that  scenario  simulation  times  were  limited  to  15 
minutes  to  keep  OPNET  simulation  time  to  approximately  3  hours.  For  instance,  OPNET 
required  2  days  to  simulate  the  Marine  scenario  with  tr  =  0.5  km,  p  =  3,  and  scenario 
simulation  time  of  15  minutes. 

B.         OVERHEAD  GENERATION 

From  Chapter  IV,  the  overhead  generated  by  the  ZRP  was  monitored  by  an 
overhead  traffic  meter  placed  in  the  process  model  of  zrpjnanager.  Figure  22  illustrates 
the  overhead  generated  by  ZRP  in  bits/sec  per  MANET  node  over  a  1 5  minute  simulation 
of  the  Marine  scenario  with  tr  =  0.2  km,  v  =  0.2  km/hr,  x_axis  =  1  km,  y_axis  =  1  km,  and 
p  incremented  from  0  to  4.  Overhead  is  considered  to  be  all  IARP,  IERP,  and  BRP  data 
generated  to  provide  routing  functionality.  IARP  overhead  is  generated  to  provide  in- 
zone  routing  and  IERP/BRP  is  generated  to  provide  out-of-zone  routing.  BRP  overhead 
is  equivalent  to  out-of-zone  query  requests  due  to  its  bordercasting  and  optimization  role. 
IERP  overhead  is  generated  by  route  replies  and  route  failure  messages.  As  depicted  in 
Figure  22,  with  a  constant  uniform  node  velocity  and  average  neighbor  density  (primarily 
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Figure  22.  ZRP  Overhead  With  Changing  Zone  Radius. 


dictated  by  transmit  radius),  the  zone  routing  radius  is  the  critical  parameter  dictating  the 
amount  of  ZRP  overhead  that  is  generated.  In  this  figure,  the  proactive  routing  overhead 
associated  with  LAPP  quickly  increases  as  p  is  expanded.  LERP  overhead  in  bits/sec 
remains  relatively  constant  and  slowly  declines  as  p  is  expanded.  The  low  LERP 
overhead  at  p  =  0  is  dictated  by  traffic  generation  among  MANET  nodes  [14].  An 
increase  in  traffic  query  demands  would  dictate  an  increase  of  LERP  overhead  at  p  =  0. 
LERP  overhead  steadily  declines  with  increasing  p  as  the  IARP  zone  routing  is  able  to 
respond  to  route  query  requests  with  its  large  route  cache  due  to  a  large  reactive  routing 
zone. 

Figure  23  is  used  to  illustrate  the  behavior  of  ZRP  overhead  (packets/sec) 
generated  per  node  with  increased  zone  routing  radius.  The  zone  radius  that  minimizes 
ZRP  overhead  can  be  experimentally  determined.  The  simulation  parameters  for  the 
Marine  scenario  are  tr  =  0.2  km,  v  =  0.2  km/hr,  x_axis  =  1  km,  y_axis  -  1  km,  and  p  is 
incremented  from  0  to  4.  The  Marine  scenario  is  measured  against  Haas  results  to  better 
depict  the  "U"  shape  of  ZRP  overhead  in  regions  outside  the  capability  of  this  scenario. 
At  p  =  0,  ZRP  overhead  is  driven  by  LERP  packets  per  second  required  to  meet  traffic 
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requirements  since  IARP  overhead  is  zero  packets/sec  in  this  region  (see  Figure  9).  In 
Figure  22,  as  p  increases,  IARP  overhead  increases  with  zone  routing  radius.  IERP 
overhead  as  a  percentage  of  ZRP  overhead  is  reduced  due  to  the  reactive  zone  cache  built 
from  proactive  IARP  routing.  The  result  is  an  overall  decrease  in  ZRP  overhead  as 
shown  in  Figure  23.  As  p  continues  to  increase,  IARP  overhead  traffic  rises 
exponentially.  As  Figure  22  illustrates,  IERP  overhead  continues  to  increase  in  this 
region  due  to  link  instability,  but  at  a  much  slower  rate  when  compared  to  IARP 
overhead. 
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Figure  23.  ZPR  Traffic  Per  Node  (After  Ref.  [4]). 


In  addition,  Figure  23  indicates  that  the  Marine  scenario  does  not  show  the 
downward  trend  in  ZRP  overhead  per  node.  This  is  due  to  the  low  traffic  generation  rate 
and  small  scale  of  the  MANET  environment  simulated  by  the  Marine  scenario  to  remain 
within  hardware  limitations.  The  Marine  scenario  also  does  not  show  a  sharp  rise  in  ZRP 
overhead  as  p  increases  and  this  is  due  to  the  limited  number  of  MANET  nodes.  The 
ZRP  overhead  in  the  Marine  scenario  reaches  a  plateau  of  IARP  traffic  generation  by  p  = 
4.    The  Haas  scenarios  of   500  and  200  node  simulations  are  provided  to  illustrate  this 

37 


behavior  which  could  not  be  simulated.  As  p  increases,  more  nodes  are  added  to  the 
zone,  thus  increasing  the  amount  of  IARP  packets/sec  per  node.  This  example  also  serves 
to  illustrate  the  earlier  point  that  ZRP  behavior  is  shaped  by  the  MANET  environment 
itself  and  ZRP  performance  will  differ  between  MANET  simulations. 

Figure  24  illustrates  the  advantage  of  a  hybrid  MANET  protocol  with  respect  to 
changing  velocity.  The  simulation  parameters  used  for  the  Marine  scenario  were  tr  =  0.2 
km,  p  =  2,  x_axis  =  1  km,  y_axis  =  1  km,  and  v  is  incremented  from  0  to  0.8  km/hr. 
IARP  is  designed  to  be  timer  based  and  independent  of  event  triggers  (neighbor 
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Figure  24.  ZRP  Overhead  With  Changing  Velocity. 

discovery/neighbor  loss).  This  is  why  the  version  of  the  time  triggered  IARP  process 
model,  IARP_LS_timer,  utilized  was  critical.  As  depicted  in  Figure  24,  the  ZRP  overhead 
remains  relatively  constant  over  the  course  of  the  simulation.  The  fluctuation  is  due  to 
IERP  that  is  impacted  by  node  velocity,  traffic  generation,  and  link  stability.  IERP  is 
responsible  for  maintaining  routes  during  transmissions  (sessions).  The  IERP  variance  is 
low  since  the  simulation  limited  the  number  of  packets/session  in  the  configuration.  With 
a  large  data  channel,   10Mbps,  the  IERP  route  repair  occurrences  remained  low.     A 
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simulation  with  longer  transmissions  (sessions)  with  a  smaller  data  channel  rate  between 
MANET  nodes  would  have  caused  a  rise  in  ZRP  overhead.  In  this  situation,  the  IERP 
overhead  would  force  the  curve  upward  due  to  the  need  to  reestablish  links,  which  were 
broken  due  to  node  mobility.  The  result  is  that  ZRP  overhead  to  support  a  MANET 
environment  is  independent  of  node  velocity. 

C.        LINK  PERFORMANCE 

Figure  25  is  provided  to  depict  the  link  performance  of  ZRP  as  the  zone  routing 
radius  is  increased.  A  result  reported  by  Haas  is  compared  to  the  Marine  scenario  to 
provide  scale  with  a  larger  MANET  simulation  with  a  higher  level  of  average  neighbor 
density.  The  Marine  scenario  represents  a  15  minute  simulation  of  the  32  node  network 
with  tr  =  0.2  km,  v  =  0.2  km/sec,  x_axis  =  1  km,  y_axis  =  1  km,  and  p  incremented  from 
0  to  4.  The  Haas  scenario  illustrates  a  simulation  of  1000  nodes  at  average  neighbor 
density  equal  to  five  [4].  As  shown  in  Figure  25,  there  is  a  correlation  between  link 
failures/sec  and  p.  The  Marine  scenario  records  approximately  0.75  failures/sec  at  p  =  0 
to  approximately  0.62  failures/sec  at  p  =  1.  For  p  <  1,  the  failures/sec  decrease  steadily 
to  0.6  failures/sec.  The  flattening  of  the  curve  in  the  Marine  scenario  is  due  to  the  small 
scale  of  the  network,  which  renders  the  routing  zone  increase  less  effective  at  large 
values.  The  decrease  is  a  constant  downward  trend  with  network  sizes  of  1000  nodes  and 
varies  according  to  node  density  [4].  Node  density,  the  average  neighbors  per  node,  is 
dictated  by  transmit  radius  and  is  not  a  function  of  p.  The  downward  trend  in  failures  is  a 
result  of  routing  zone  expansion  which  provides  increased  reliability.  The  ZRP 
mechanism  which  increases  reliability  is  BRP.  Instead  of  having  to  route  through  each 
node  to  the  destination,  BRP  provides  an  optimum  routing  mechanism  which  exploits 
available  IARP  link-state  information  in  each  routing  zone  for  optimization,  thus 
decreasing  hop  count  to  destinations.  The  Haas  example  illustrates  the  impact  of 
neighbor  density  that  amplifies  the  routing  optimization,  which  can  be  achieved  from  the 
proactive  routing  zone  cache  of  IARP.  Neighbor  density  is  increased  by  increasing 
transmit  radius  of  each  MANET  node.  There  is  a  difference  of  approximately  0.1 
failures/sec  between  the  two  cases  until  p  =  2.  This  decreases  the  potential  for  link  failure 
(route  unable  to  be  established)  due  to  node  movement,  channel  interference,  and  other 
factors  associated  with  links  between  nodes.  As  a  result  of  using  ZRP,  the  link 
performance  increases  as  the  zone  routing  radius  is  increased. 
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Figure  25.  Link  Failure  Percentage  With  Increasing  Zone  Routing  Radius  (After  Ref.  [4]). 

The  purpose  of  Figure  26  is  to  evaluate  the  impact  of  velocity  on  link  performance 
with  ZRP  if  the  zone  routing  radius  is  held  constant.  The  simulation  parameters  used 
with  the  Marine  scenario  for  Case  1  were  tr  =  0.2  km,  p  =  2,  x_axis  =  1  km,  y_axis  =  1 
km,  and  v  was  incremented  from  0  to  0.8  km/hr.  At  p  =  0,  the  link  failure  percentage  of 
the  Marine  scenario  was  approximately  57%.  As  the  zone  routing  radius  was  increased, 
the  failure  percentage  continued  to  rise.  An  increase  in  node  velocity  decreased  the 
ability  to  maintain  route  stability.  The  time  to  transmit  a  message  over  the  link  becomes  a 
problem  due  to  shorter  periods  of  route  stability  with  increased  node  mobility.  The 
deviation  from  this  upward  trend  at  v  =  0.8  km/hr  was  unexpected.  A  repeat  simulation 
with  a  different  seed  value,  Case  2  on  Figure  26,  did  not  produce  a  large  variation  from 
the  previous  simulation.  When  the  simulation  was  repeated  at  a  lower  neighbor  density, 
Case  3  (transmit  radius  tr  =  0.1  km),  inconclusive  results  were  observed.  The  link  failure 
rate  hovers  at  95%  with  no  distinct  trends.  The  link  failure  percentage  was  expected  to 
have  increased  with  velocity  in  both  situations.  This  does  occur  in  both  Case  1  and  Case 
2  until  an  anomaly  at  0.8  km/hr.  Case  1,  with  transmit  radius  tr  =  0.1  km,  does  not  echo 
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this  trend.  At  v  =  0  km/hr,  the  link  failure  percentage  is  94.66%  and  does  rise  to  96.22% 
at  v  =  0.6  km/hr.  However,  there  is  a  decrease  in  link  failure  percentage  at  v  =  0.4 
km/sec.  The  Marine  scenario  fails  to  produce  a  distinct  ZRP  behavior. 
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Figure  26.  Link  Failure  Percentage  With  Changing  Velocity:  Case  1,  2,  and  3  With  p  =  2. 


D. 


EFFICIENCY  AND  OPTIMIZATION 


An  important  goal  of  this  thesis  was  to  look  at  the  efficiency  of  this  algorithm. 
Efficiency  (r|)  was  measured  as  follows: 

r|=  I  /(I  +  OH) 


where  I  is  the  amount  of  information  data  bits  and  OH  is  the  amount  of  overhead  bits.  At 
p  =  0,  ZRP  is  producing  minimal  overhead  and  is  at  maximum  efficiency.  As  the  zone 
routing  radius  increases,  ZRP  overhead  increases  rapidly  due  to  IARP  overhead  which 
quickly  decreases  the  efficiency.  However,  due  to  the  small  size  of  the  Marine  network, 
the  decay  quickly  reaches  a  steady  state.     Figure  27  displays  efficiency  and  link 
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completion  percentage  as  a  function  of  zone  routing  radius  and  depicts  the  tradeoff 
between  efficiency  and  link  performance.  As  discussed  earlier,  the  ideal  zone  routing 
radius  is  when  IERP  and  IARP  traffic  are  balanced.  From  this  diagram,  from  a  pure 
efficiency  standpoint  we  can  determine  that  the  ideal  zone  routing  radius  would  be  p  =  1 . 
This  zone  routing  setting  would  provide  the  least  amount  of  inefficient  routing  with  a 
large  link  completion  percentage.  All  values  of  zone  routing  radius  greater  than  1  provide 
a  marginal  increase  in  link  completion  along  with  a  decrease  in  routing  efficiency. 
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Figure  27.  ZRP  Data  Efficiency. 


In  accordance  with  the  ZRP  min-searching  and  adaptive  traffic  method  of  routing 
optimization  discussed  in  Chapter  IE,  the  optimal  setting  for  the  Marine  MANET 
environment  would  be  p  =  1.  Figure  28  displays  routing  zone  optimization  using  the 
measurements  at  each  interval.  IERP  only  dominates  in  the  p  =  0  setting,  where  the  ratio 
of  IERP  overhead  to  IARP  overhead  (IERP/IARP)  goes  to  infinity  since  IARP  traffic  is  0. 
The  closest  setting  to  achieving  balance  between  IERP  and  IARP  traffic  is  at  p  =  1 .  The 
min-searching  method  assumes  that  the  traffic  of  each  node  does  not  change  drastically 
over  time  and  would  determine  popt  in  the  following  manner.  Figure  22  is  more 
applicable  to  this  method.  As  depicted  in  Figure  22,  starting  at  p  =  0,  the  IERP  traffic  and 
IARP  traffic  are  both  on  the  rise.  The  undershoot  situation  is  realized  with  IERP  traffic 
increasing.  At  p  =  1,  both  IARP  and  IERP  are  increasing;  this  would  be  determined  as  an 
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undershoot  region.  For  p  >  1,  IERP  is  decreasing  and  IARP  is  increasing  which  points  to 
an  overshoot  situation.  Therefore,  popt  =  1  is  forced  by  the  adaptive  traffic  method. 
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Figure  28.  IERP/IARP  Routing  Zone  Optimization. 

E.         SUMMARY 

The  Marine  scenario  configured  for  this  analysis  was  hampered  by  a  Windows  NT 
platform  which  could  only  support  32  MANET  nodes  with  an  average  neighbor  density 
of  3-5  nodes.  The  Marine  scenario  failed  to  demonstrate  the  complete  behavior  of  ZRP 
when  compared  to  the  results  reported  by  Hass  [4].  This  echoes  the  point  that  ZRP 
behavior  will  be  different  in  various  MANET  environments.  The  overhead  traffic 
generated  by  ZRP  was  broken  down  into  component  (IARP,  IERP,  and  BRP)  traffic. 
IARP  overhead  traffic  provides  the  majority  of  routing  traffic  as  the  zone  routing  radius  is 
increased.  The  amount  of  IARP  traffic  is  a  function  of  node  neighbor  density.  The  "U" 
shape  behavior  of  ZRP  overhead  per  node  was  not  realized  in  the  Marine  scenario.  The 
amount  of  traffic  generated  by  the  limited  number  of  MANET  nodes  was  not  sufficient  to 
mirror  this  behavior.  ZRP  proved  to  be  relatively  independent  of  velocity  in  the  Marine 
scenario.  Due  to  the  low  traffic  generation  rate,  the  variation  in  IERP  overhead  traffic 
was  minimal.  The  ability  to  communicate  does  improve  as  the  zone  routing  radius  is 
increased.  However,  this  effect  became  minimal  at  large  zone  routing  radius  values  in  the 
Marine  scenario.    The  effect  of  changes  in  velocity  on  MANET  nodes  running  ZRP 
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proved  to  be  inconclusive.  Despite  varying  the  average  neighbor  density,  no  distinct 
behavior  was  identified.  In  the  Marine  scenario,  p  =  1  was  proved  to  be  the  optimal  zone 
routing  radius  by  the  min-searching  and  traffic  adaptive  methods.  There  was  a  distinct 
tradeoff  between  routing  efficiency  and  link  performance  when  adjusting  the  zone  routing 
radius. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 

A.         CONCLUSIONS 

The  results  of  this  thesis  provided  a  snapshot  into  the  performance  of  ZRP  in  a 
small  generic  mobile  ad  hoc  network  chosen  to  represent  a  future  JTRS  architecture  on 
the  relative  scale  of  a  single  Marine  rifle  platoon  operating  in  a  1  square  kilometer  area  of 
operation.  The  complete  behavior  of  ZRP  was  not  demonstrated  in  the  Marine  scenario 
due  to  the  limited  number  of  nodes  (32),  the  low  traffic  generation  ,  and  the  small  x-  and 
y-axis  boundaries  due  to  performance  limitations  of  the  Windows  NT  platform.  Previous 
results  reported  by  Haas  and  Pearlman  were  used  as  a  rheostat  to  scale  the  results  from 
the  Marine  scenario  to  the  behavior  of  ZRP  in  that  of  a  much  larger  network  with 
MANET  environment  parameters  outside  of  the  capabilities  of  this  work. 

The  traffic  overhead  behavior  of  ZRP  in  the  Marine  scenario  was  consistent  with  a 
hybrid  MANET  protocol.  With  constant  velocity  and  average  neighbor  density  (primarily 
dictated  by  transmit  radius),  the  zone  routing  radius  proved  to  be  the  critical  parameter 
dictating  the  amount  of  ZRP  overhead  generated  in  the  Marine  scenario.  IARP  overhead 
traffic  increased  rapidly  as  the  zone  routing  radius  is  increased.  The  small  size  of  the 
network  forced  the  IARP  traffic  increase  to  level  off  when  it  would  otherwise  continue  to 
increase  in  a  larger  network  with  greater  neighbor  density.  IERP  traffic  overhead  is 
driven  by  the  traffic  generation  of  the  source  nodes.  IERP  overhead  traffic  caused  ZRP 
overhead  fluctuations  in  the  presence  of  changes  in  velocity.  IERP  is  responsible  for 
repairing  routes,  and  this  activity  is  slightly  increased  as  a  result  of  route  instability 
introduced  by  velocity.  However,  the  periodic  behavior  of  IARP  is  independent  of  node 
velocity  and  was  unaffected  by  adjustments  to  node  velocity  with  the  Marine  scenario. 

ZRP  link  performance  was  improved  in  the  Marine  scenario  by  increasing  the 
zone  routing  radius.  When  compared  to  previous  research,  a  decrease  is  more  continuous 
with  network  sizes  of  1000  nodes  and  varies  according  to  node  density  [4].  The 
variations  in  neighbor  density  could  not  be  effectively  measured  due  to  the  limitations 
with  the  Windows  NT  platform.  The  increase  in  link  performance  was  diminished  due  to 
the  small  scale  of  the  network  simulation,  which  rendered  the  zone  routing  radius 
increase  less  effective  at  large  values.  The  link  performance  of  ZRP  appears  to  be 
directly  related  to  node  velocity  in  the  Marine  scenario.  However,  the  results  were 
inconclusive.    In  general,  as  the  node  velocity  increases,  the  ability  to  maintain  link 
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stability  decreases.  The  time  to  transmit  a  message  over  the  link  becomes  a  problem  with 
increased  velocity  due  to  short  periods  of  route  stability. 

In  accordance  with  the  min-searching  and  traffic  adaptive  method  of  routing 
optimization,  the  optimal  setting  for  the  Marine  MANET  environment  would  be  p  =  1. 
IERP  only  dominated  in  the  p  =  1  setting  where  the  ratio  of  IERP/IARP  goes  to  infinity 
since  the  IARP  traffic  is  zero  in  this  region.  The  closest  setting  to  achieving  balance 
between  IERP  and  IARP  traffic  is  at  p  =  1 .  The  Marine  scenario  demonstrated  that  ZRP 
is  able  to  adapt  to  MANET  environments  through  adjustments  to  the  zone  routing  radius. 
Analysis  relating  link  completion  with  zone  efficiency  produced  an  intersection  point 
prior  to  the  optimum  zone  radius.  In  the  Marine  scenario,  the  small  size  of  the  network 
produced  flat  curves  once  the  zone  routing  radius  exceeded  1 .  However,  this  technique 
may  prove  to  be  unreliable  in  a  larger  network  since  network  performance  and  network 
efficiency  would  continue  to  rise  and  fall,  respectively. 

B.         RECOMMENDATIONS 

The  scenario  configured  for  protocol  analysis  is  critical  to  accurately  model  a 
MANET  protocol's  behavior.  Future  studies  of  ZRP  or  other  MANET  protocols  should 
incorporate  simulations  that  are  able  to  model  a  larger  set  of  MANET  nodes  in  a  larger  x- 
y  plane.  The  author  suggests  using  at  least  100  nodes  or  more.  Neighbor  density  level 
limitations  due  to  computer  hardware  should  reduced  for  future  research.  A  small 
network  was  not  sufficient  to  model  all  aspects  of  ZRP  behavior.  Traffic  generation  from 
the  MANET  nodes  should  be  elevated  to  better  model  the  IERP  overhead  behavior  for 
small  zone  routing  radius  values.  The  larger  traffic  flow  will  also  provide  better  feedback 
on  the  behavior  of  ZRP  in  regions  of  changing  velocity.  During  each  session 
(transmission),  multiple  packets  should  be  transmitted  to  provide  data  on  packet 
interarrival  delay  over  the  MANET  network.  The  data  rate  of  the  channel  should  be 
reduced  significantly  to  resemble  more  realistic  levels.  Third  generation  cellular 
networks  will  have  2  Mbps  throughput.  Marine  Corps  tactical  radios  currently  are  only 
capable  of  9.6  kbps. 

The  ZRP  OPNET  model  utilized  in  this  work  does  not  incorporate  several 
important  MANET  environment  factors  in  its  current  form.  Power  levels,  ad  hoc  traffic, 
formation  movements,  transmit  radius,  and  ad  hoc  velocity  would  more  accurately  model 
the  military  battlespace  for  JTRS  implementation.  Battery  power  remains  a  critical 
concern  to  the  tactical  radio  operator.     The  IARP  process  should  be  modified  to 
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incorporate  a  low  power  indicator  for  each  mobile  node.  The  BRP  should  be  able  to 
leverage  this  proactive  data  in  the  route  optimization  process.  The  node  movement 
should  be  modified  to  create  association,  so  groups  of  nodes  could  move  about  the 
battlespace.  This  group  behavior  would  further  improve  the  capability  of  the  ZRP 
protocol.  The  group  behavior  would  provide  more  consistent  neighbors  throughout  the 
simulation  and  mirror  real  world  tactical  formations.  Furthermore,  the  speed  of  each 
node  or  groups  of  node  should  be  made  ad  hoc  to  further  enhance  the  realization  of  the 
tactical  scenario.  Vehicle,  foot  mobile,  helicopter,  and  aircraft  traffic  could  be 
represented  by  varying  the  velocity  of  some  nodes.  Ad  hoc  transmit  radius  capabilities 
would  provide  a  more  realistic  battlespace  model.  Foot  mobile  traffic  would  carry 
limited  range  squad  radios.  Vehicles,  helicopters,  and  aircraft  would  have  significantly 
larger  ranges  and  bridge  the  battlespace. 

ZRP  is  a  simple  hybrid  MANET  protocol  that  has  a  great  deal  of  potential  for 
JTRS.  However,  more  in  depth  study  and  analysis  is  required  to  explore  its  capabilities. 
Comparison  of  ZRP  with  other  MANET  protocols  over  identical  simulations  should 
provide  the  level  playing  field  for  evaluation.  It  is  hoped  that  this  thesis  has  provided 
insight  into  the  ZRP  protocol  and  its  potential  application  to  a  small  ad  hoc  mobile 
network  operating  in  a  tactical  environment. 
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